Data transfer networks include network elements such as, for example, routers, switches, and terminal devices which communicate with each other via data transfer links between the network elements. In many data transfer networks, there is a need to achieve phase- or at least frequency-synchronization between clock signals prevailing at various network elements. Furthermore, in some data transfer networks, there can be a need to achieve time-synchronization between different network elements in such a way that not only phases and/or frequencies of clock signals but also time values maintained in these network elements are sufficiently close to each other. In other words, each of the network elements should maintain a time value that is common to all network elements under consideration. The common time value is usually called as “wall clock time” or “universal time”. In this document, the term “synchronization” means frequency-synchronization, phase-synchronization, time-synchronization, or any combination of them.
Network elements can be configured to constitute master-slave pairs in order to distribute timing information within a data transfer network. For example, a slave network element may be configured to control its clock signal generator so that a reference clock signal prevailing at the corresponding master network element is regenerated in the slave network element at least partly on the basis of reception moments of timing messages transferred from the master network element to the slave network element, where the reception moments are expressed as time values based on the clock signal prevailing at the slave network element. The timing messages can be, for example, time-stamps contained by data frames that can be, for example, Internet Protocol “IP” data packets or Ethernet data frames. Each time-stamp indicates the instantaneous time value at the transmission moment of the respective data frame containing the time-stamp under consideration, where the time value is based on the reference clock signal available at the master network element. For another example, the timing messages can be timing data frames that are transmitted so that the time interval between transmission moments of two successive timing data frames is constant, or otherwise known, when being measured with the reference clock signal available at the master network element. It is also possible that one or more time-stamps indicating the transmission moments of one or more timing messages are transferred in one or more data frames transmitted after the one or more timing messages. In cases where the time-synchronization is needed, the timing information is not only transferred from the master network element to the slave network element but also in the opposite direction from the slave network element to the master network element. A way of achieving the time-synchronization is presented, for example, in the specification 1588 issued by the Institute of Electrical and Electronics Engineers, “IEEE 1588”.
In many cases, the reception moment of a data frame carrying or representing a timing message should be stored immediately after the arrival of the data frame at the network element because subsequent processing actions directed to the received data frame may take a stochastic amount of time, and thus storing the reception moment after these processing actions would cause a stochastic component on the stored value of the reception moment. Stochastic components of the kind mentioned above in the stored reception moments destroy or at least weaken the quality of the synchronization. An inherent inconvenience related to storing the reception moments before the above-mentioned processing actions is that, just after reception of a data frame, it is typically difficult to find out whether the received data frame belongs to those data frames whose reception moments needs to be stored. For example, a network element may receive an aggregate flow which consists of several flows of data frames, and only a small portion of the flows may be such flows that the reception moments of data frames belonging to these flows needs to be stored. The flow recognition is typically based on inspection of the received data frames, but there can be a complex encapsulation so that many data transfer protocols are involved in each data frame. This makes it difficult to carry out the inspection within a sufficiently short and deterministic time. A straightforward brute-force solution would be to store the reception moments of all the received data frames together with e.g. copies of at least parts of the data frames and settle later which of the stored reception moments are needed in the synchronization. This straightforward brute-force solution requires, however, a lot of memory and processing capacity.